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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
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Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

It defines the functionality required for interworking High PErformance Radio Local Area Network Type 2 
(HIPERLAN/2) with IEEE 802.3 Local Area Networks [5]. Separate ETSI documents provide details on the system 
overview, data link control layer, radio link control sublayer, other convergence sublayers and conformance testing 
requirements for HIPERLAN/2. 

The Packet based Convergence Layer is split into two parts, a Common Part and a Service Specific Part. The Common 
Part describes the functionality for adapting variable length packets/frames to the fixed size data units used at the Data 
Link Control (DLC) layer while the Service Specific part describes the functionality required to support a certain 
protocol, e.g. Ethernet or IP. It is envisioned that several, independent. Service Specific Convergence Sublayers (SSCS) 
will be defined in the future as market requirements develop. The SSCSs all use the services of the Common Part and 
the DLC. 

The present document is part 2 of a multi-part deliverable covering the Packet based Convergence Layer, as identified 
below: 

Parti: "Common Part"; 

Part 2: "Ethernet Service Specific Convergence Sublayer (SSCS)"; 

Part 3: " IEEE 1394 Service Specific Convergence Sublayer (SSCS)"; 

Part 4: "IEEE 1394 Bridge Specific Functions sub-layer for restricted topology"; 

Part 5: "IEEE 1394 Bridge Specific Functions sub-layer for unrestricted topology". 

Part 1 describes the functionality for adapting variable length packets/frames to the fixed size used in the Data Link 
Control (DLC) layer. Further parts, each defining a Service Specific Convergence Sublayer (SSCS), describe the 
functionality required to support a certain protocol, e.g. IEEE 1394 [7] or Ethernet protocols. The SSCSs all use the 
services of the Common Part and the DLC [2]. It is envisioned that several, independent, service specific parts will be 
defined in the future as market requirements develop. As a result, further parts may be added in the future. 
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Scope 



The present document is applicable to HIPERLAN/2 equipment supporting interworking with IEEE 802.3 Local Area 
Networks [5]. 

The present document does only address the functionality required to transfer IEEE 802.3 [5] frames over the radio 
interface between an HIPERLAN/2 Access Point and Mobile Terminal. Note that the frame type described in 
IEEE 802.3 [5], also covers Ethernet v2 (see bibliography). The present document does not address the requirements 
and technical characteristics for wired network interfaces at the Access Point and at the Mobile Terminal. 

The present document supports both best effort and the IEEE 802. Ip priority mechanisms developed to enable 
Quality-of-Service in LANs. 

The present document uses the services provided by the Common Part of the Packet based Convergence Layer and by 
the Data Link Control layer of HIPERLAN/2. 

The present document does not address the requirements and technical characteristics for conformance testing. Those 
are covered in separate documents. 
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3.1 



Definitions, symbols and abbreviations 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

Maximum Transmission Unit (MTU): maximum packet size in octets that can be conveyed in one piece over a link 

Protocol Data Unit (PDU): data unit exchanged between entities at the same ISO layer 

Service Data Unit (SDU): data unit exchanged between adjacent ISO layers 



3.2 Symbols 



For the purposes of the present document, the following symbol applies: 
Ox Hexadecimal notation 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AP Access Point 

BRAN Broadband Radio Access Networks (Project) 

CL Convergence Layer 

CPCS Common Part Convergence Sublayer 

C-SAP Control Service Access Point 

DLC Data Link Control 

DLCC DLC Connection 

DUC DLC User Connection 

HIPERLAN/2 High Performance Radio Local Area Network Type 2 

H/2 see HIPERLAN/2 

IE Information Element 

IEEE Institute of Electrical and Electronics Engineers 

IP Internet Protocol 

IPv4 IP version 4 

IPv6 IP version 6 

LAN Local Area Network 

LLC Logical Link Control 

LSB Least Significant Bit 

M-SAP MAC Service Access Point 

MAC Medium Access Control 

MSB Most Significant Bit 

MX Mobile Terminal 

MTU Maximum Transmission Unit 

PDU Protocol Data Unit 

QoS Quality of Service 

RLC Radio Link Control 

RFC Request For Comments 

SAP Service Access Point 

SDU Service Data Unit 

SFD Start Frame Delimiter 

SSCS Service Specific Convergence Sublayer 

TCI Tag Control Information field 

TCP Transmission Control Protocol 

TPID Tag Protocol Identifier 

UDP User Datagram Protocol 
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Overview 



The Ethernet Service Specific Convergence Sublayer is a part of the Packet based Convergence Layer and it resides on 
top of the Common Part and the DLC. It provides a method of using and preserving the IEEE 802.3 frame format over 
the radio interface by adapting service requests for transmission and reception of 802.3 frames to bearer services offered 
by the DLC. 

All Mobile Terminals (MT), associated to the same AP, appear like connected to one common fixed shared medium 
LAN segment. In contrast to a normal fixed LAN segment where all terminals are able to listen to all traffic on the 
segment, traffic that is originated by one MT is always first sent up to the AP. It is then the task of the AP to relay the 
traffic to either the fixed network and/or to other MTs associated to that AP. 

The network topology when applied to HIPERLAN/2 is shown in figure 4.L Please note that the scope of the Ethernet 
SSCS is limited to the radio interface only (shaded in grey). The architecture of the AP, e.g. if it only contains Layer 2 
(i.e. MAC bridging) functionality or if it also includes Layer 3 (i.e. IP routing) functionality, is not standardized. 
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Figure 4.1 : HIPERLAN/2 network topology using Ethernet SSCS 

The corresponding protocol model for Ethernet SSCS is depicted in figure 4.2. The Ethernet SSCS replaces the MAC 
entity in the IEEE 802 model. At the MT, the CL User Service Access Point is mapped to the M-SAP, the SAP between 
IEEE 802.2 (LLC) and the IEEE 802.3 (MAC) layers. At the AP, the Ethernet SSCS replaces the IEEE 802.3 MAC 
entity and interacts with the MAC relay entity of an IEEE 802. ID bridge. 
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Application 



E.g. TCP/UDP 



E.g. IP 



Ethernet V2 or 
IEEE 802.3 / 802.2 framing 



Packet based CL - 
Ethernet SSCS 



Packet based CL - Common Part 



HIPERLAN/2 DLC 



HIPERLAN/2 PHY 



Scope of BRAN specifications 



Packet based C[>--.. IEEE 802.1 D ^^^ 
Ethernet SSCS ^^--...^including IEEE 802.1^^,...^^ 


Packet based CL - Common Vd^cC"''^-^^^^^^^^^ 


HIPERLAN/2 DLC 


Network specific 

protocols, 

out of scope 


HIPERLAN/2 PHY 



HIPERLAN/2 l\Jlobile Terminal 



HIPERLAN/2 Access Point 



Figure 4.2: Ethernet SSCS architecture applied to HIPERLAN/2 

The Ethernet SSCS supports two QuaHty-of-Service types: 

a) Best Effort 

This is the defauh QoS type that shall be supported. All traffic is treated equally and no Quality-of-Service guarantees 
can be provided. 

b) IEEE 802.1p priority based QoS scheme 

IEEE 802. Ip provides priority mechanisms to enable Quality-of-Service in Local Area Networks. These mechanisms 
have been incorporated into IEEE 802. ID [4]. Eight (numbered 0-7) different priority levels are defined. The user 
priorities are mapped one-to-one or many-to-one to queues, depending on the number of queues supported. In 
HIPERLAN/2 each queue corresponds to one DLC user connection. The mapping between user priorities and DLC user 
connections is defined in clause 5.4.2. The user priority information is carried in each IEEE 802.3 frame using a Tag 
Header inserted following the source and destination address. The Tag Header is defined in [6] (see clause 5.3.2 for 
more details on supported frame types). The support for IEEE 802. Ip is optional for both the MT and AP. 

The Quality-of-Service type and additional parameters used by the SSCS are negotiated at association time using the 
control plane procedures defined in clause 6. 

The Ethernet SSCS consists of a user plane and a control plane. The user plane, described in clause 5, provides services 
to the Higher Layer via the CL-Service Access Point (SAP) and uses the services of the Common Part of the Packet 
based Convergence Layer [1]. The control plane of the Ethernet SSCS, described in clause 6, interacts with the DLC 
control plane, i.e. the RLC sublayer, via the DLC Control SAP. The DLC Control SAP is defined in [2]. 



User plane 



5.1 



General 



The user plane procedures of the Ethernet SSCS provide the capability to transfer Ethernet SSCS SDUs between the 
Ethernet SSCS of the AP and one or more Ethernet SSCSs of MTs over the HIPERLAN/2 network. 

It is the task of the Ethernet SSCS to map the address and priority scheme of the Higher Layer to the address and 
priority scheme of the DLC layer. 

Ethernet SSCS SDUs coming from the Higher Layer are mapped onto different DLC user connections, depending on 
the Ethernet destination address and priority. The relation between Ethernet address/priority and DLC user connections 
is managed by the Ethernet SSCS control plane (see clause 6). 
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The behaviour of the user plane procedures for AP and MT is asymmetric. All MTs transfer all Ethernet SSCS SDUs to 
the Ethernet SSCS of the AP. It is the task of the Ethernet SSCS of the AP to reflect Ethernet SSCS SDUs back to the 
HIPERLAN/2 network, if necessary to emulate the behaviour of a shared medium LAN segment (see clause 5.3). The 
AP directs the Ethernet SDUs to one Ethernet SSCS in case of unicast. In case of multicast and broadcast the AP directs 
the Ethernet SDU to one or more Ethernet SSCS of MTs, if multiple MTs have subscribed to a multicast group or if 
multiple MTs have associated to the AP. 

5.2 Primitives (informative) 

The Ethernet SSCS exchanges service primitives with the Higher Layer and the CPCS. 

NOTE: The primitives are defined only for the purpose of describing layer-to-layer and sublayer-to-sublayer 

interactions. These primitives are defined as an abstract list of parameters, and their concrete realization 
may vary between implementations. No formal testing of primitives is intended. The following primitive 
definitions have no normative significance. 

5.2.1 Primitive types 

Interface between layers 

Four primitive types may be used between different layers: 

req (request), for a higher layer to request service from a lower layer; 

cnf (confirm), for the layer providing the service to confirm the activity has been completed; 

ind (indication), for a layer providing service to notify the next higher layer of any specific service related 
activity; 

rsp (response), for a layer to acknowledge receipt of an indication primitive from the next lower layer. 

Interface between sublayers 

Two different primitives may be used between different sublayers. To indicate the absence of a Service Access Point 
these primitives differ to the primitives between different layers. 

inv (invoke), for a higher layer to request service from a lower layer; 

sig (signal), for a layer providing service to notify the next higher layer of any specific service related activity. 

The defined types for each category of primitive are shown as a list in curly brackets. 

EXAMPLE: CL_UNITDATA {req, ind} 

In this example, the defined types are request and indication but not confirm or response. 

5.2.2 Parameter definitions 

Endpoint identifiers: some primitives contain an endpoint identifier. This identifier shall be used to distinguish 
primitives related to different protocol instances. As identifier the DLC User Connection ID, which is the concatenation 
of a MAC_ID and DLCCJD [3], shall be used. The coding of this identifier is a local matter not defined in the present 
document. The identifier is defined as: 

- DLC User Connection ID (DUC_ID) 

Message unit: each piece of higher layer information that is included in the primitive is called a message unit. A series 
of one or more message units may be associated with each primitive where each separate unit is related to one 
information element in the corresponding DLC layer message. The list of message units is derived from the message 
definitions by reference to the information elements that may contain information from or (to) the CL. 
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5.2.3 Interface to the Ethernet Layer 

The following primitives are used 
CL_UNITDATA {req, ind} 



PARAMETER 


REQ 


CNF 


IND 


RSP 


Message units (possible elements) 
Destination address 
Source address 
Interface Data (SSCS-SDU) 
Priority 


A 
A 
A 



- 


A 
A 
A 


- 


NOTE: A = Always present; 
= Optional; 
"-" = Not applicable. 



Destination address 

This parameter specifies a 48-bit IEEE MAC Destination Address as defined in [5]. 

Source address 

This parameter specifies a 48-bit IEEE MAC Source Address as defined in [5]. 

Interface Data 

This parameter specifies the Interface Data exchanged between the Higher Layer and the Ethernet SSCS entity. The 
Interface Data represents a complete Ethernet SSCS-SDU. The types of SDUs that shall be supported are described in 

clause 5.3.2. 

Priority 

This parameter specifies the priority assigned to each Ethernet SSCS-SDU according to IEEE 802.1D [4]. 

5.2.4 Interface to the Common Part 

The interface to the Common Part of the Packet based Convergence Layer is defined in [1]. 

5.3 Functionality 
5.3.1 General 

The Ethernet Service Specific Convergence Sublayer functions are performed on an Ethernet SSCS-PDU basis. The 
Ethernet SSCS accepts different types of frames. The types that shall be supported are described in clause 5.3.2. 

The functions implemented by the Ethernet SSCS user plane include: 

a) Preservation of Ethernet SSCS-SDU 

This function provides the delineation and transparent transfer of Ethernet SSCS-SDUs. 

b) Traffic class mapping according to 802. Ip (optional) 

This function provides the mapping of different traffic classes to different priority queues, depending on how many 
priority queues are supported. 

c) Mapping of Ethernet broadcast to HIPERLAN/2 DLC broadcast service 

This function provides the mapping of Ethernet broadcast to the broadcast service offered by the HIPERLAN/2 DLC. 

d) Mapping of Ethernet multicast to HIPERLAN/2 DLC multicast service 

This function provides the mapping of Ethernet multicast to the multicast service offered by the HIPERLAN/2 DLC. 



£75/ 



11 



ETSI TS 101 493-2 VI .2.1 (2001-12) 



e) Emulation of a collision domain 

This function provides that MTs associated to the same AP appear to be connected as if connected to a shared medium 
LAN segment. 

To emulate the behaviour of a shared medium LAN segment the following functionality is required: 

At the Access Point 

Ethernet frames shall be reflected back to the radio interface in case of: 

Ethernet broadcast frames if an MT associated to the AP is the source; 

Ethernet multicast, if one or more MTs associated to the same AP have registered to the same multicast group 
and one MT associated to the AP is the source; 

Ethernet unicast, if an MT sends frames destined to another MT that is associated to the same AP. 

In case of multicast and broadcast, the Ethernet frames shall also be forwarded to the Higher Layer. 

At the Mobile Terminal 

Ethernet traffic that has been reflected back to the radio interface shall be filtered out and discarded by the 
originating MT; 

The Higher layer shall not receive Ethernet frames that have been sent by itself before. 



5.3.2 Coding of the Ethernet SSCS PDU 



The Ethernet SSCS shall accept the Ethernet frame types described in figures 5.1 and 5.2. The Ethernet frames shall be 
mapped to the CPCS-SDU beginning with the Destination Address field and ending with the Payload (including 
Padding if present). Preamble, Start Frame Delimiter (SFD) and Frame Check Sequence (FCS) shall be omitted. 

In contrast to the transmission order specified for Ethernet [5], where the least significant bit is transmitted first on the 
physical medium, the Ethernet SSCS-PDUs shall be transmitted according to the transmission order defined in the 
DLC [3] and RLC [2], see also annex A. 



Preamble 


SFD 


Destination 
Address 


Source 
Address 


Type/ 
Length 


Variable Length payload 


PAD 


FCS 


7 1 


6 6 2 46-1500 


4 




SSCS SDU / SSCS PDU / CPCS SDU 





60-1514 octets 

Figure 5.1 : IEEE 802.3 frame 

Tag Header 

■* ► 
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Address 
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Address 


TPI 
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Variable Length payload PAD 


FCS 


7 1 


6 6 2 2 2 42-1500 


4 




SSCS SDU / SSCS PDU / CPCS SDU 





60-1518 octets 

Figure 5.2: IEEE 802.3 frame with IEEE 802.3ac Tagging 
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5.4 Procedures 

5.4.1 General 

The procedures of the Ethernet SSCS, defined in the following clauses, are asymmetric and thus differ between Access 
Point and Mobile Terminal. 

5.4.2 Procedures at the sender - Access Point 

NOTE 1 : The following parameters have no normative significance. The parameters are only defined for the 
purpose of describing the procedures of sender and receiver. 

The sender maintains the following parameters: 

<MAC ID tablo 

This table is shared by sender and receiver within one CL entity. Entries are set by control functions and entries are read 
by the sender and the receiver. The table maps IEEE 802 MAC Addresses to DLC MAC_IDs, see annex C. It is 
possible that multiple MAC_IDs are associated to one IEEE 802 MAC address in case Ethernet multicast is sent as 
DLC unicast. 

<Number of DLC Connections tablo 

Entries in this table, reflecting the negotiated number of DLC connections for each MAC_ID, are set by control 
functions during association and read by the sender. The number of DLC Connections shall be set to a value from 1 to 
8. 

<DUC_ID> 

The DUC_ID identifies the instance of the Common Part to which the CPCS_UNITDATA invoke primitive is sent. The 
DUC_ID is the concatenation of MAC_ID and DLCC_ID. 

The AP sender shall perform the following procedures: 

1) Upon reception of a CL_UNITDATA request primitive the sender validates if one or more MAC_IDs are 
registered for the <Destination address> by querying the <MAC ID tablo. 

If there is no MAC_ID registered for this <Destination Address>, the SSCS-SDU shall be discarded and the 
sender waits for the next CL_UNITDATA request. 

If there are one or more MAC_IDs registered for the <Destination address>, the sender shall duplicate the 
Ethernet SSCS-SDU for each MAC_ID that is registered and shall proceed with the steps listed below for each 
Ethernet SSCS SDU: 

2) The sender shall set the DLCC_ID: 

If the <Destination address> in the Ethernet SSCS-SDU is the 48-bit IEEE broadcast address as specified in [5], 
the DLCC_ID shall be set to 63. 

If the <Destination address> in the Ethernet SSCS-SDU is any of the 48-bit IEEE multicast addresses as 
specified in [5], the DLCC_ID shall be set to 63 if the related MAC_ID is one of the multicast MAC_IDs 
(224-255). If the related MAC_ID is not a multicast MAC_ID, the DLCC_ID shall be set according to tables 5.1 
and 5.2, depending on the entries of the <Number of DLC Connections tablo and the <Priority> received in the 
primitive. 

If the Ethernet SSCS-SDU is an Ethernet unicast, the DLCC_ID shall be set according to tables 5.1 and 5.2, 
depending on the entries of the <Number of DLC Connections tablo and the <Priority> received in the 
primitive. 

3) The sender shall construct the SSCS-PDU as shown in clause 5.3.2. It then sends the CPCS_UNITDATA invoke 
primitive to the CPCS instance identified by the <DUC_ID>. 
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IEEE 802. Ip defines 8 priorities and describes which type of traffic is expected to be carried in this priority. Priority 
number 2 is currently reserved for future use. The mapping between user priority, traffic type, traffic class and 
DLCC_ID is described in tables 5.1 and 5.2. Different traffic classes are mapped to different DLCCs. After connection 
setup the RLC indicates which DLCC_IDs have been assigned to DLCCs in a list (see clause 6.4) and traffic classes are 
mapped to DLCC_IDs depending on the numerical order of the value of the DLCCJDs, as shown in table 5.2. 

Table 5.1 : IEEE 802.1 p Traffic Types [4] 



User priority 


Traffic Type 


Comments 


1 


Background (BK) 




2 


- 


Spare 


(Default) 


Best Effort (BE) 


Default LAN traffic 


3 


Excellent Effort (EE) 


For valued customers 


4 


Controlled Load (CL) 


Traffic will have to conform to some 
form of Higher Layer admission control 


5 


"Video" (VI) 


< 100 ms delay and jitter 


6 


"Voice" (VO) 


< 10 ms delay and jitter 


7 


Network Control (NC) 





Table 5.2: Mapping between IEEE 802.1 p and DLCC-ID 



Number of 
DLCCs 


Traffic Classes 


DLCC-ld 


1 


{ Best Effort, Excellent Effort, Background, Voice, Controlled 
Load, Video, Network Control } 


Lowest 


2 


{ Best Effort, Excellent Effort, Background } 

{ Voice, Controlled Load, Video, Network Control } 


Lowest 
2"'^ lowest 


3 


{ Best Effort, Excellent Effort, Background } 
{ Controlled Load, Video } 
{ Voice, Network Control } 


Lowest 
3"^ lowest 
2"'^ lowest 


4 


{ Background } 

{ Best Effort, Excellent Effort } 
{ Controlled Load, Video } 
{ Voice, Network Control } 


4"^ lowest 
Lowest 
3''^ lowest 
2"'^ lowest 


5 


{ Background } 

{ Best Effort, Excellent Effort } 

{ Controlled Load } 

{ Video } 

{ Voice, Network Control } 


4"^ lowest 
Lowest 
3''^ lowest 
5"^ lowest 
2"'^ lowest 


6 


{ Background } 

{ Best Effort } 

{ Excellent Effort } 

{ Controlled Load } 

{ Video } 

{ Voice, Network Control } 


4"^ lowest 
Lowest 
6"^ lowest 
3''^ lowest 
5"^ lowest 
2"'^ lowest 


7 


{ Background } 

{ Best Effort } 

{ Excellent Effort } 

{ Controlled Load } 

{ Video } 

{ Voice} 

{ Network Control } 


4'*^ lowest 
Lowest 
6"^ lowest 
3''^ lowest 
5"^ lowest 
2"'^ lowest 
7'*^ lowest 


8 


{ Background } 
{ Best Effort } 
{ Excellent Effort } 
{ Controlled Load } 
{ Video } 
{ Voice} 

{ Network Control } 
{ Spare } 


4'*^ lowest 
Lowest 
6'*^ lowest 
3''^ lowest 
5"^ lowest 
2"'^ lowest 
7'*^ lowest 
8'*^ lowest 
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NOTE 2: The traffic types written in bold are the distinguishing trafl'ic types that have driven the allocation of types 
to classes. The "Spare" queue is reserved for future use. The traffic type for this queue has not been 
specified in 802. Ip. 

EXAMPLE: The RLC indicates that the following DLCCJDs have been assigned to DLCCs: [DLCC_ID=6, 
DLCC_ID=4]. The traffic class {Best effort, Excellent Effort, etc.} shall be mapped to 
DLCC_ID= 4, as this is the lowest DLCC_ID number, while the traffic class { Voice, Controlled 
Load etc.} shall be mapped to DLCC_ID=6. 

5.4.3 Procedures at the sender - Mobile Terminal 

NOTE 1 : The following parameters have no normative significance. The parameters are only defined for the 
purpose of describing the procedures of sender and receiver. 

The sender maintains the following parameters: 

<Number of DLC Connections> 

This parameter is set by control functions during association and read by the sender. It reflects the negotiated number of 
DLC connections. It shall be set to a value from 1 to 8. 

<DUC_ID> 

The DUC_ID identifies the instance of the Common Part to which the CPCS_UNITDATA invoke primitive is sent. The 
DUC_ID is the concatenation of MAC_ID and DLCC_ID. 

The MT sender shall perform the following procedures: 

1) The sender shall set the DLCC_ID according to tables 5.1 and 5.2, depending on the <Number of DLC 
Connections> and the <Priority> received as parameter. 

2) The sender shall construct the SSCS PDU as shown in clause 5.3.2. Then it sends the CPCS_UNITDATA 
invoke primitive to the CPCS instance identified by the <DUC_ID>. 

NOTE 2: Ethernet broadcast and multicast originated by the MT is sent as unicast traffic to the AP. The AP 
distributes this traffic if applicable. 

5.4.4 Procedures at the receiver - Access Point 

NOTE: The following parameters have no normative significance. The parameters are only defined for the 
purpose of describing the procedures of sender and receiver. 

The receiver maintains the following parameters: 

<MAC ID tablo 

This table is shared by sender and receiver within one CL entity. Entries are set by control functions and entries are read 
by the sender and the receiver. The table maps IEEE 802 MAC Addresses to DLC MAC_IDs. It is possible that 
multiple MAC_IDs are associated to one IEEE 802 MAC address in case of multicast, see also annex C. 

<DUC_ID> 

The DUC Identifier identifies the instance of the Common Part to which the CPCS_UNITDATA invoke primitive is 
sent. The DUC_ID is the concatenation of MAC_ID and DLCC_ID. 

The AP receiver shall perform the following procedures: 

1) When the receiver receives a CPCS_UNITDATA signal primitive the receiver examines the value of the 
destination address, which is always sent in the first 6 octets of the Interface Data. 

2) If the destination address is equal to the 48-bit IEEE 802 MAC broadcast address, the receiver shall invoke the 
sender procedure at the same entity with the Interface Data. The sender shall treat the SDU as if it was received 
in a CL_UNITDATA request. The receiver shall create a CL_UNITDATA indication primitive including the 
parameters. Source Address, Destination Address and Interface Data and send it also to the Higher Layer. 
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3) If the destination address is equal to any 48 -bit IEEE 802 MAC multicast address, the receiver shall invoke the 
sender procedure at the same entity with the Interface Data. The sender shall treat the SDU as if it was received 
in a CL_UNITDATA request, but it may filter out the SDU back to the originating MT, to avoid unnecessary 
traffic duplication. The receiver shall create a CL_UNITDATA indication primitive including the parameter 
Source Address, Destination Address and Interface Data and send it also to the Higher Layer. 

4) If the destination address is equal to any 48 -bit IEEE 802 MAC unicast address and a MAC_ID is registered for 
this address, the receiver shall invoke the sender procedure at the same entity with the Interface Data. The sender 
shall treat the SDU as if it was received in a CL_UNITDATA request. 

5) In all other cases the receiver shall create a CL_UNITDATA indication primitive including the parameters. 
Source Address, Destination Address and Interface Data and send it to the Higher Layer. 

5.4.5 Procedures at the receiver - Mobile Terminal 

The receiver maintains the following parameter: 

<Own IEEE address> 

This parameter is used to filter traffic that has been sent by the MT and was subsequently received by it. The parameter 
corresponds to the 48-bit IEEE 802 MAC address of the Mobile Terminal. 

The MT receiver shall perform the following procedures: 

1) When the receiver receives a CPCS_UNITDATA signal primitive the receiver shall compare the Source 
Address, the six octets following the Destination Address of the Interface Data, to the parameter <Own IEEE 
address>. 

2) If the Source Address is equal to the value of <Own IEEE address>, the Interface Data shall be discarded. 

3) If the Source Address is not equal to the value of <Own IEEE address>, the receiver shall create a 
CL_UNITDATA indication primitive including the parameters. Source Address, Destination Address and 
Interface Data and send it to the Higher Layer. 



Control Plane 



6.1 General 

The control plane of the Ethernet SSCS interacts with the DLC control plane (i.e. the RLC sublayer) via the DLC 
Control Service Access Point defined in [2]. 

The following functions are performed by the control plane procedures of the Ethernet SSCS: 

a) Implicit QoS type negotiation during association and network handover (using DLC connection setup 
procedures); 

b) Triggering of MT originated DLC connection setup at association and network handover; 

c) Triggering of DLC multicast and broadcast join procedures; 

d) AP network address transfer during association and network handover; 

e) MT IEEE 802 MAC address transfer during association and network handover. 

The following DLC C-SAP primitives [2] are used by the control plane procedures of the Ethernet SSCS: 

- DLC_SETUP- {req, ind}; 

- DLC_CONNECT - { req, cnf , ind, rsp } ; 

- DLC_MULTIC ASTJOIN - { req, cnf, ind, rsp } ; 
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DLC_MULTICAST_LEAVE - {req, ind}; 
DLC_CL_BROADCAST_JOIN - {req, cnf, ind, rsp}; 
DLC_INFO_TRANSFER - {req, cnf, ind, rsp}. 



6.2 Convergence Layer specific parameters 



6.2.1 Convergence Layer Identifier 

The Convergence Layer ID used in the RLC [2] shall be set according to the table below to indicate the support of 
Ethernet SSCS in the MT and AP. Bits 6 to 8 identify the Convergence Layer. In case of the Packet based Convergence 
Layer bits 1 to 5 identify the Service Specific Convergence Sublayer (SSCS). 



Bits 8765432 1 



Meaning 



10 Ethernet SSCS supported 
All other values are reserved for other Convergence Layers. 



6.2.2 Convergence Layer Version 



The Convergence Layer Version number is an 8-bit field used in the RLC [2]. This field is split into two 4-bit subfields. 
The four most significant bits (bits 5 to 8) identify the version of the Common Part and the four least significant bits 
(bits 1 to 4) identify the version of the SSCS. The Convergence Layer Version number shall be set according to the 
table below to indicate the support of this edition (version 1) of the Ethernet SSCS. 



Bits 8765432 1 



xxxxOOO 1 



Cleaning 



Ethernet SSCS version 1 supported 



6.2.3 Maximum Transmission Unit 

The Maximum Transmission Unit (MTU) used in the Common Part of the Packet based Convergence Layer [1] shall be 
set to 1 518 octets. 



6.3 



Information Elements for Ethernet SSCS 



6.3.1 



Information element format 



In order to transfer Convergence Layer specific information between AP and MT a number of CL information elements 
are defined. These Convergence Layer specific information elements are transferred transparently by RLC messages 
within the RLC specific information element «CL-ATTRIBUTES» [2]. Each Convergence Layer information 
element consists of a Type field, a Length field and an Information field, see figure 6.1. 

The purpose of the Information Element Type is to identify the information element being sent. The IE Type field is 8 
bits, allowing for up to 256 information elements to be defined for a certain SSCS. 

The Reserved field is for future use and shall be coded as zero. 

The Length field indicates the length of the Information field in octets. It does not include the length of the IE Type 
field, the Reserved field, or the length of the Length field itself. 
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8 7 


6 


Bits 
5 4 3 


2 


1 


IE Type 


Reserved 


Lengtti (L) 


Information 



Octets 

1 

2 
3 



L + 2 



Figure 6.1 : Convergence Layer information element structure 



6.3.2 Information element type coding 

The following IE Type codes are used in the Ethernet SSCS: 
Bits 8 7 6 5 4 3 2 1 



00000000 
0000000 1 



Meaning 



IEEE 802 IVIAC Address (see clause 6.3.3) 
AP Networl< Address (see clause 6.3.4) 



6.3.3 



All other values are reserved for future lEs. 



IEEE 802 MAC Address IE 



The «IEEE 802 MAC Address» information element is used to inform the AP of the MT's IEEE 802 MAC address 
during association and handover. The information element is also used in the multicast and broadcast procedures to 
inform the AP about the IEEE 802 MAC address of a certain multicast or broadcast group it wants to join or leave (in 
case of multicast). 



Octets 

1 

2 
3 
4 
5 
6 
7 



Figure 6.2: IEEE 802 MAC Address information element 

6.3.4 AP Network Address IE 

The purpose of the «AP Network Address» information element is to facilitate routing of network handover 
messages between APs via the fixed network. It is also used to inform the MT about a change of the network topology, 
e.g. change of IP subnet, during a handover. The AP shall provide this IE to the MT at association time and at Network 
Handover. The MT shall provide the IE to the new AP during Network Handover. The address type used in the network 
is out of scope of the present document. 



8 7 


Bits 
6 5 4 3 


2 


1 


«IEEE 802 MAC Address» 


Reserved 


Length (L) 


MSB 


IEEE 802 MAC Address 




LSB 
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Address Type (octet 4) 



Bits 8 7654321 



00000000 
00000001 
00000010 
0000001 1 



Meaning 



IEEE 802 48 bit MAC address 
IEEE EUI-64 address 
IP version 4 address 
IP version 6 address 



All other values are reserved for future use. 



AP Network Address (octet 5. . .) 



Address Type 


Reference 


Length (octets) 


IEEE 802 48 bit I\/1AC address 


[51 


6 


IEEE EUI-64 


[7] 


8 


IP version 4 address 


RFC 791, [8] 


4 


IP version 6 address 


RFC 2373, [9] 


16 



AP IPv4 Subnet Mask (32 bits) 

The AP IPv4 Subnet Mask is used to inform the MT about the subnet mask of the IP subnet to which the AP is attached. 
This field is optional and only valid together with an IP version 4 address type in the AP to MT direction. The subnet 
mask has a length of 32 bits. 



Octets 

1 

2 
3 
4 



8 7 


Bits 
6 5 4 3 


2 


1 


«AP-NETWORK-ADDRESS» 


Reserved 


Length (L) 


Address Type 


MSB 


AP Network Address 







LSB L + 2 



Figure 6.3: AP Network Address information element 





Bits 






8 7 


6 5 4 3 


2 


1 


«AP-NETWORK-ADDRESS» 


Reserved 


Length (= 5 or 9) 


Address Type = IPv4 


MSB 


AP IPv4 address 




LSB 


MSB 


AP IPv4 Subnet mask 




LSB 



Octets 

1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
_11 

NOTE: AP IPv4 Subnet mask is optional and only used with an IPv4 address. 
Figure 6.4: AP Network Address information element (for IPv4 address + IPv4 Subnet mask) 
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AP IPv6 Prefix Length (8 bits) 

The AP IPv6 Prefix Length is used to inform the MT about the length of the IPv6 address prefix of the AP. This field is 
optional and only valid together with an IP version 6 address type in the AP to MT direction. The Prefix Length is a 
binary coded value specifying how many of the leftmost continuous bits of the address comprise the prefix. 



Octets 

1 

2 
3 
4 



8 7 


Bits 
6 5 4 3 2 1 


«AP-NETWORK-ADDRESS» 


Reserved 


Length (=17 or 18) 


Address Type = IPv6 


MSB 


AP IPv6 Network Address 



LSB 19 

:20 



: AP IPv6 Prefix Lengtii 

NOTE: AP IPv6 Prefix Lengtii is optional and only used with an IPv6 address. 
Figure 6.5: AP Network Address information element (for IPv6 address + IPv6 Prefix Length) 



6.4 



Procedures 



6.4.1 Association 

The information field of the «CL-ATTRIBUTES» IE in the DLC_INFO_TRANSFER request primitive triggered by 
the MT during association, see [2], shall contain the following CL information element: 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


IEEE 802 MAC address 


Clause 6.3.3 


M 


8 


Contains the IEEE 802 MAC address of the MT 



Upon receiving a DLC_INFO_TRANSFER indication the AP shall update the <MAC ID table> with the IEEE 802 
MAC address of the MT received in the «CL-ATTRIBUTES» IE and the MAC ID assigned to the MT by the DEC. 

The AP shall then respond with a DLC_INFO_TRANSFER response primitive. The information field in the 
«CL-ATTRIBUTES» information element sent in the primitive shall contain the following CL information element: 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


AP Network Address 


Clause 6.3.4 


M 


7-20 


Contains the network address of the AP 



Upon receiving a DLC_INFO_TRANSFER the MT shall then trigger a connection setup by issuing a DLC_SETUP 
request primitive including the number of connections it wants to use. One DLCC equals best effort mode, while 
2 to 8 DLCCs indicate that the MT wants to use IEEE 802. Ip. 

Upon receiving a DLC_SETUP indication primitive the AP shall compare the number of connections requested by the 
MT with the number of connections supported by the AP. The AP decides on the number of DEC connections that shall 
be used. However, the value chosen shall not exceed the number of connections requested by the MT. The AP sets the 
<Number of DEC connections table> entry for the MAC ID of the MT and shall then respond with a DLC_CONNECT 
request primitive including the number of DLC connections the MT shall use. 

Upon reception of a DLC_CONNECT indication primitive the MT shall set the <Number of DLC connections> 
parameter. 
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The MT shall then issue a DLC_CL_BROADCAST_JOIN request primitive containing the Ethernet broadcast address 
(Ox) FF:FF:FF:FF:FF:FF. This address shall be transferred by the IEEE 802 MAC address information element within 
the «CL_ATTRIBUTES» IE, see below. 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


IEEE 802 MAC address 


Clause 6.3.3 


M 


8 


Contains the IEEE 802 MAC broadcast address 
(Ox) FF:FF:FF:FF:FF:FF 



Upon reception of DLC_CL_BROADCAST_JOIN indication primitive the AP shall add the IEEE 802 MAC broadcast 
address and the broadcast MAC ID allocated by the DEC to the <MAC ID table>. 

The AP then issues a DLC_CL_BROADCAST_JOIN response primitive. The SSCS in the AP shall indicate to the user 
plane that the MT has been successfully associated and user plane operation may commence 

The MT receives a DLC_CL_BROADCAST_JOIN confirm primitive including the MAC ID allocated by the AP for 
Ethernet broadcast. An indication is sent to the user plane that the MT is associated and user plane operation may 
commence. 

NOTE: A single MAC ID is allocated by the AP for all Ethernet broadcasts. 

The details of the association procedure are shown in annex B. 

6.4.2 Network HancJover 

For the CL the procedures for Network Handover are the same as the association procedure described in the previous 
clause, with the following exceptions: 

1) The «CL-ATTRIBUTES» IE in the DLC_INFO_TRANSFER request primitive triggered by the MT during 
network handover, see [2], shall contain also the AP Network Address of the old AP, see below. 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


IEEE 802 MAC address 


Clause 6.3.3 


M 


8 


Contains the IEEE 802 MAC address of the MT 


AP Network Address 


Clause 6.3.4 


M 


7-19 


Contains the network address of the old AP 



The AP Network Address shall be the address of the AP to which the MT was associated before the handover. This 
information may be used by an inter- AP handover protocol specified in the future. 

2) After the connection setup the MT should join the multicast groups, see clause 6.4.3, which it had joined at the 
oldAP. 

NOTE: If Network Handover is supported via the core network the DEC C-S AP primitives triggered by the CL 
may be ignored by the RLC. 

6.4.3 Multicast 

The «CL-ATTRIBUTES» information element in the DLC_MULTICAST_JOIN request primitive triggered by the 
MT shall contain the following information element: 



Information Element 


Reference 


Status 


Total length 
(octets) 


Description 


IEEE 802 MAC address 


Clause 6.3.3 


M 


8 


Contains the IEEE 802 MAC multicast group 
address the MT wants to join. 



NOTE: The MT may request to join several multicast groups simultaneously, in which case several IEEE 802 
MAC address lEs will be included in the «CL-ATTRIBUTES» in the DLC_MULTICAST_JOIN 

primitives. 
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Upon reception of a DLC_MULTICAST_JOIN indication primitive the AP updates the <MAC_ID table> with the 
IEEE 802 MAC multicast address received from the MT and the corresponding MAC ID allocated by the AP. This can 
either be a multicast MAC ID or a unicast MAC ID. Each IEEE 802 MAC multicast group address can correspond to 
several MAC IDs. 

The AP triggers a DLC_MULTICAST_JOIN response primitive. Upon reception of DLC_MULTICAST_JOIN 
confirm the MT user plane operation for this multicast address may commence. Filtering for this multicast address at 
the MT is handled in the DEC layer. 

The DLC_MULTICAST_LEAVE primitive triggered by the MT shall contain the IEEE 802 MAC address of the 
multicast group the MT wants to leave, as in the multicast join procedure (see above). Upon reception of a 
DLC_MULTICAST_LEAVE indication the AP shall remove the entry for that multicast group from the <MAC ID 
table> if the MT was the only member of the multicast group. 

6.4.4 Miscellaneous 

When the AP notices that an MT has left or upon reception of a disassociation indication the AP shall remove all entries 
in the <MAC ID Table> for that MT. If the MT was the only member of a multicast group the entry for that group shall 
be removed. 



Ethernet SSCS MIB 



The Management Information Base parameters for the Ethernet SSCS of the Packet based Convergence Layer will be 
defined in the H/2 Network Management Technical Specification. These MIB parameters may be moved into this 
clause in a future edition of the present document. 
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Annex A (normative): 

Numbering and Coding Conventions 

Information elements and PDUs are transferred between the Ethernet SSCS and the underlying protocol layers in units 
of octets, in ascending numerical octet order (i.e. octet 1, 2, .., n-1, n), see figure A.l. 



MSB 



Bits 
5 4 



LSB 
1 Octets 



n-1 



Figure A.l : Format convention 

When a field is contained within a single octet, the highest bit number (i.e. the bit labelled 8) represents the high order 
or most significant bit (MSB). 

In a multi-octet field the order (i.e. the significance) of bit values within each octet decreases as the octet number 
increases. For example, a 16-bit field is coded in the following way, see figure A.2. 



MSB 
8 


7 


6 


5 


Bits 
4 


3 


2 


LS 

1 


2^^ {MSB) 


214 


213 


2i2 


2ii 


2io 


29 


28 


2' 


26 


25 


2' 


23 


2' 


2' 


2° (LSB) 



Figure A.2: Corresponding coding in an IE or PDU 
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Annex B (informative): 

Association procedure for Ethernet SSCS 

Figures B.l to B.4 highlight the sequence of RLC procedures at association time that is specific to the Ethernet SSCS. 



MSC Association Etiiernet SSCS 



Unk_Agreed_or_Encryption_active_or_Authenticated 



Info Transfer 



Setup_Raclio_Connection_mobile_originated 



CL_Broadcast_Join 



User_plane_operation_started 



Figure B.l : High-level association procedure for Ethernet SSCS 
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MSC Info Transfer 



1 MT_CL 1 1 MT_ACF | MT_RLC | 


1 AP_RLC 1 1 AP_ACF | | AP_CL | 




II II 






/ Link_Agreed_or_Encryption_active_ 


orAuthenticated \ 




DLCJf 


FO_TRANSFER.req 


ACFJnfo^req 


RLCJNFO 


ACFJnfoJnd 


dlc_info_tran; 






FO_TRANSFER.cnf 






ACFJnfo_cnf 






RLC_INFO_ACK 








ACFJnfo_rsp 


FER.ind 




DLC_INFO_TRANSF ER.rsp 




















DLCJ^ 













MT_Associated_to_AP 



Figure B.2: Info transfer procedure 
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MSC CL Broadcast Join 



MT CL 



MT ACF MT RLC 



AP RLC AP ACF 



AP CL 



Setu p_Rad io_Con nectio ncom pleted 



DLC_CL_BROADCAST_JOIN.cnf 



DLC_CL_BROADCAST_JOIN.req 



ACF cl broadcES 



RLC_CL_BR 



ACFcLbrciadcast Joincnf 



;t_join_req 
RLC_CL_BROADCAST 



OADCAST_JOIN_ACK 



JOIN 
ACFcLbroadcistJoinJnd 



DLC_CL_BROADCAST_JOIN.rsp 



ACF_cl_broadcastJoin_rsp 



DLC CL BROADCAST JOIN.ind 



Figure B.3: CL Broadcast Join procedure 
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MSC SETUP_RADIO_CONNECTION_MOBILE_ORIGINATED 



MT CL MT ACF MT RLC 



AP RLC AP ACF AP CL 



MT Associated to AP 



DLC_SETUP.re(i 



DLC C;ONNECT.ind 



DLC CONNECT. 



DUC_setup_req 



DUG connect ind 



.rsp 
DUC connect 



RLC SETUP 



DLC_ 
DUC_connect_req 



RLC CONNECT 



.n;p 



RLC CONNECT ACK 



DUC_setup_ind 



CONNECT.req 



DUC connect cnf 



DLC SETUP.ind 



DLC CONNECT.cnf 



Setup_Radio_Connection_Completed 



Figure B.4: MT originated DUC setup procedure 
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Annex C (informative): 
Example of the IVIACJD table 



The MAC_ID table consists of mappings between Ethernet unicast, muhicast and broadcast addresses to HIPERLAN/2 
MAC_IDs. In case of unicast and broadcast only one MAC_1D is used per Ethernet address. Ethernet multicast is 
mapped to HIPERLAN/2 unicast MAC_IDs and/or to HIPERLAN/2 multicast MAC_IDs (see table C.l). 

Table C.I : Example of the <MAC ID table> in the AP 



IEEE 802 MAC Address 
(48 bits) 


MAC IDs 


Broadcast address: 




(Ox) FF:FF:FF:FF:FF:FF 


223 


Multicast addresses: 




(0x)01:00:5E:00:00:00 


1,2,6 


(0x)01:00:5E:01:02:10 


225 


(0x)01:00:5E:12:B1:00 


3,2 


(0x)01:00:32:21:A1:01 


4,6 


MT addresses: 




(Ox) 00 


10:5A:2D:4D:83 


1 


(Ox) 00 


12:5A:3D:4D:82 


2 


(Ox) 00 


1 1 :4A:2C:33:43 


3 


(Ox) 00 


10:4E:2E:22:12 


4 


(Ox) 00 


11:2E:A1:11:A2 


5 


(Ox) 00 


12:3E:11:2A:1A 


6 
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